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Abstract. This paper describes security protocols that use anonymous 
channels as primitive, much in the way that key distribution protocols 
take encryption as primitive. This abstraction allows us to focus on high 
level anonymity goals of these protocols much as abstracting away from 
encryption clarifies and emphasizes high level security goals of key distri- 
bution protocols. The contributions of this paper are (f) a notation for 
describing such protocols, and (2) two protocols for location protected 
communication over a public infrastructure. 


1 Introduction 

As mobile devices for communication and computation gain more widespread 
acceptance, where a person is located when processing digital information or 
sending and receiving messages or phone calls is increasingly under individual 
control. Relatedly, individuals no longer tied to an office have enjoyed increas- 
ing privacy over their location information. If one can conduct business from 
anywhere, then one can be anywhere when conducting business. However, this 
is not an entirely accurate picture. For example, mobile phones may not reveal 
one’s location to the party at the other end of the line as readily as stationary 
ones, but currently implemented technology still requires tracking of the mobile 
phone itself. 

The primary purpose of phones is to allow individuals to communicate. 
Where anyone happens to be, and even who they are, is simply coincidental 
to that communication. Technology that more precisely reflects the functional 
needs of the intended application would therefore provide anonymous channels 
of communication. The communication over such a channel need not be anony- 
mous; parties typically will identify themselves over the channel, but the channel 
itself should not reveal their locations or identities to the network or observers 
of the network. This paper describes protocols that use anonymous channels as 
primitives. After sketching the requirements for a channel to be anonymous we 
use such channels to construct protocols for location protected mobile applica- 
tions. One such application we have already mentioned. Specifically, our protocol 
allows a mobile phone to send and receive calls without revealing its location to 
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anyone, including the communications infrastructure on which it relies. A side 
benefit of our protocol is that its implementation would potentially extend the 
useful battery life of a phone in standby (listening) mode by orders of magnitude. 

Another, less well known but increasingly important, application of mobile 
communication is in location tracking. This has already been implemented in 
the Lo-Jack system that allows police to track a car that has been reported 
stolen and in an active badge system implemented by Olivetti at the Comput- 
ing Laboratory at Cambridge University. It is also an important component of 
ITS (intelligent transport systems, cf., below). As an example we describe active 
badge systems. Like current mobile phones, these do not fully protect location 
information. In fact quite the opposite. The purpose of such a system is to track 
the location of those wearing the badges. This can be useful, e.g., in an environ- 
ment where individuals are not always in their offices but it is important to be 
able to find them when needed. While useful, active badges can have overtones 
of big brother, as they allow a company to track things such as how long an 
individual is in the cafeteria. One way to reduce this threat is to give individuals 
control over their location information. Such concerns have led to the proposal of 
protocols for doing just that [7]. These protocols allow individuals to keep their 
location information in a designated repository over which they have access con- 
trol. Not even the tracking system is able to determine where an individual is 
without consulting the designated repository. This paper also presents protocols 
for individual control of location information in a tracking system. Our approach 
is related to that of Jackson in [7] but has important differences. One difference 
is that all versions proposed in [7] require the badge to produce or carry route 
information for each message it sends. Our approach requires only the produc- 
tion of an adequately random string of one-time identifiers. This means that 
the Jackson approach decentralizes the control of location information, which 
appears to be good, and makes the badge operation more complicated, which 
appears to be bad. Our approach allows for simple badges but requires a cen- 
tralized database. This centralization might appear to be a vulnerability, but we 
shall see that it is not. 

Intelligent transport systems are designed to track the movement of vehicles 
on appropriately structured public highways. Some of the advantages of such a 
system include route optimization for individual vehicles, traffic control for all 
vehicles so enabled, and traffic signal control for emergency vehicles. However, 
there is great potential for abuse in such a system [8]. In addition to civil rights 
and privacy abuses similar to the problems described above for badging systems, 
the potential exists for other, perhaps more serious threats. For example, truck 
hijackers could make use of a system that tracks the movement of a fleet of trucks 
to optimize their chances for a successful and lucrative hijacking. Kidnappers, 
terrorists, murderers, etc. could trace someone, even if, e.g., she intentionally 
took varying routes to work each day. 

While the private location tracking protocol described in this paper is ex- 
plained in terms of the active badging example, it is a general protocol for private 
location tracking using a public infrastructure. Thus, it applies equally well to 



vehicle tracking in ITS or an enhanced Lo-Jack system. In fact, this protocol is 
a special case of location protected communication using a public infrastructure, 
where what is communicated is itself location information. 

The remainder of the paper is structured as follows: In section 2 we give an 
overview of anonymous channels and present our notation for describing proto- 
cols that make use of them. In section 3 we set out two protocols, a protocol 
for location protected communication over cellular phones in section 3.1 and a 
protocol for private location tracking in section 3.2. In section 4 we present back- 
ground information. In particular, we briefly describe onion routing, a system we 
have implemented for anonymous communication over the Internet. In section 5 
we present our conclusions. 

2 Anonymous Channels 

For us, an anonymous channel is a communication channel for which it is in- 
feasible to determine both endpoints. The principal initiating the connection is 
the imitator, and the principal to whom he connects is the responder. These 
are not merely theoretical constructs; we have implemented a mechanism for 
anonymous channels (in fact near real-time anonymous connections) that oper- 
ates below the application layer and supports a variety of Internet applications 
[10, 11]. The design of our mechanism can be applied to non-Internet applica- 
tions such as are described in this paper. We will give more background on our 
design in section 4.1. Just as the strength of an encryption algorithm is rela- 
tive to assumptions about everything from special restrictions on the key space 
and on other inputs to the capabilities and collateral information of a poten- 
tial attacker, so too what we mean by “infeasible” will have many caveats and 
limitations for any given mechanism to implement an anonymous channel. Fortu- 
nately, for protocol purposes we need not specify these any more than we need to 
specify properties of cryptographic algorithms and their implementations when 
we describe, for example, a protocol for authenticated key distribution. 

In practice, we do assume that the initiator knows the responder: since he 
initiates the connection, he presumably knows to whom he intends to connect. 
Note that this assumes either a means to authenticate the responder or, in the 
case of one way communication, a means to guarantee that only the responder 
can receive the message, e.g., public key encryption. In theory, the initiator may 
be sending out a proverbial note in a bottle, destined for where he does not 
know. However, unlike a shipwrecked sailor on a desert island, our initiator will 
have reason to believe that his messages can ordinarily be tracked back to him 
the moment he releases them. Therefore, he will need to assure himself that his 
messages have drifted far enough away from him before anyone can begin to 
track them. Thus, even if he wishes to establish an anonymous channel with 
whomever will respond, he needs to determine a point away from himself before 
which the channel will not emerge. 

The initiator may build an anonymous connection all the way to the re- 
sponder. This would protect both of them from association with the channel 



by all but the initiator. However, since the initiator often needs only to hide 
that communication is coming from or going to him, in practice we may only 
have half-anonymous channels. In other words, the initiator produces a channel 
which cannot be traced to him and uses this to contact the responder. From 
the end of the anonymous part of the channel to the responder anyone can see 
what the responder is sending and receiving. If end-to-end encryption is piped 
through this half-anonymous channel, it can effectively be made fully anony- 
mous. Nobody can tell what the responder is sending or receiving or to whom 
the responder is connected. The only thing that can be observed from the outside 
is that the responder is talking to someone. (This too can be hidden if the chan- 
nel is maintained even when not in use and dummy traffic sent over it. However, 
such countermeasures are quite expensive.) 

Note that anonymous channels are not explicitly required to be confidential 
channels. However, cleartext is obviously trackable. And, even ciphertext that 
appears the same everywhere is trackable. Thus, for the reasons we have been 
describing, an anonymous channel must be encrypted in a changing manner at 
least to a point where it is acceptable that the communication be tracked. 

Before going further, we contrast anonymous channels with a related but dis- 
tinct form of channels, specifically subliminal or covert channels. In theory, all of 
these are channels for which it is infeasible to detect the existence of the channel. 
Thus, our distinction deals more with the expected environment for a channel 
rather than the channel’s undetectability in that environment. In practice, chan- 
nels called ‘subliminal’ typically piggyback on legitimate channels between the 
principals. Covert channels either piggyback similarly or exist in a medium that 
is not explicitly a communications medium at all. So, covert and subliminal 
channels are channels that rely on some other type of channel or computation to 
hide them. (In most applications the covert or subliminal channel will be some- 
how illegitimate and the cover channel or computation legitimate.) By contrast, 
anonymous channels rely on other anonymous channels to hide them. The cover 
for these channels are other channels like them, and the hiding comes from the in- 
distinguishability of these channels from each other. Another important contrast 
between these types of channels is their relative efficiency. Though not always 
the case, covert and subliminal channels are typically inefficient as compared to 
the legitimate communication they parallel. Anonymous channels are expected 
to be roughly comparable in efficiency to their non-anonymous counterparts in 
the same medium. We have found this to be the case in our implementation. 

2.1 Anonymous Connections 

The channels we consider for these applications are connection based. Thus, we 
will typically speak of anonymous connections rather than anonymous channels 
in general. We denote the sending of message M along an anonymous connection 
from X to Y by l X =>x Y : M\ It may be important to know if a message is 
being sent over an anonymous connection from initiator to responder or vice 
versa. Specifically, it may be important to know whose identity is protected 
from association with the channel. This is the purpose of the subscript in the 



just introduced notation. If Y sends X a message M' on an anonymous channel 
that X initiated, this is denoted ‘Y =^x A : M'\ Sending M on an ordinary 
(non-anonymous) connection from X to Y is denoted 1 X —>■ Y : M\ 

Observation: X =>x Y — >■ Z : M implies X =>x Z : M . 

2.2 Replies to Anonymous Connections 

It is also possible for the initiator to make available information that allows a 
specific or arbitrary responder to establish a connection back to the initiator. 
This connection will be anonymous just as if it were a connection established 
from the initiator. We call such a connection a reply-to-anonymous (RTA) con- 
nection. The data structure that allows a principal to make an RTA connection 
to X is denoted ‘(=>x A}’. Note that if the responder builds the RTA connection 
on the end of an anonymous connection in which he is the initiator, the result 
is a connection in which neither principal can be identified (unless he sends 
identifying information through the connection). 

3 Mobile Applications 

We now consider some applications of anonymous channels. Specifically, we de- 
scribe how anonymous connections may be used to hide location information in 
cellular phone and location tracking systems. 

3.1 Location Hiding for Cellular Phones 

First we will describe how to make calls to a cellular phone without requiring the 
phone to reveal its location. Then we will describe how to hide the location of 
a caller’s cellular phone from the both the network and external eavesdroppers. 
There are other solutions with similar anonymity goals that contain many of the 
elements in our protocol [2, 3]. Our protocol focuses on simple yet anonymous 
communication on top of an energy efficient call-back architecture. 

In current cellular phone systems, the location of a phone is tracked, so calls 
to that phone can be routed through the base station controlling the phone’s 
current cell. This tracking has two disadvantages: One is that the system knows 
where phones are. The other is that phones must transmit frequently to update 
their locations. This drains the phone’s battery quickly. 

In our proposal, instead of tracking a phone’s location, phones will be paged. 
When such a phone is called, the network invents a temporary number and 
pages the phone. The phone’s response to the page will be to make a call back 
to the temporary number in the page. The phone network will then mate the 
two connections. In addition to overcoming the disadvantages just mentioned, 
this simplifies our protocol because we effectively need to describe only how to 
initiate a call from a cell phone; the phone never receives a call in the ordinary 
sense of ‘receive’. We will return to discuss paging briefly below. 



The principals specified in our protocol are the caller’s cell phone P, the 
central switch S, and the callee intended to receive the call R. We now present 
our protocol for initiating a call from a cell phone. 

1. P Op S : Payment info., N 

2. S Op P : Ack or Nack 

3. P Op S R : Conversation 

To make a call from a cellular phone without revealing location, the phone 
makes an anonymous connection to a central switch. It then sends to the switch 
the number it is trying to reach, together with some payment information to 
cover billing. The payment information may be the phone’s subscriber ID or 
a credit card number or even anonymous e-cash of some sort. N is either R’s 
phone number in the outgoing case or the temporary number from the page 
in the incoming case. Assuming that the payment information is acceptable 
the switch allows the call to be completed. In the outgoing case, the switch 
completes the call to R and patches this to the anonymous connection from P. 
In the incoming case, the switch allows the the connection from R to be patched 
to the anonymous connection from P. 

Since we are only trying to hide location, the anonymous connection need 
not be made all the way from the caller to the callee. Rather, the anonymous 
connection is made to some central switch in the network, from which it can 
be passed along in the clear. This switch will not know from where the call is 
coming; however, it will not complete the call unless the phone sends identify- 
ing information or some guarantee of payment. (We do not here discuss how 
identification is authenticated.) 

There is nothing in the protocol description to indicate that we are dealing 
with mobile phones. Of course with stationary phones, location protection of a 
given phone is moot. But, the protocol still protects the location origin of a call 
made from that phone. In fact, this sort of protection for stationary phones is dis- 
cussed in [9] . It is helpful to have a notation abstract enough to cover anonymity 
in both these stationary phone connections and the mobile connections of [2, 3]. 
This is as it should be because the means to establish anonymous connections is 
separate from the basic communication medium that underlies it. For example, 
in our Internet implementation (cf. section 4.1) the underlying network is free to 
make whatever dynamic routing choices between points that it ordinarily does, 
provided that it connects to the points we do specify. Thus, the usual mobile 
phone procedures for connection to local base station and hand-offs between base 
stations as a phone changes cells are unaffected by our anonymous connections. 
The fact that there is movement in the cellular phone network is not hidden 
from the network; however, who is talking and where they are is hidden. So, the 
network is untrusted in this sense. 

Our combination of anonymous connections and paging has two advantages. 
The locations of inactive phones do not need to be tracked within a paging 
region. Also phones never need to transmit except when they are involved in 
a call. This greatly reduces battery drain. For example, pagers last for a few 
months on a single battery, while cell phones last about a day in standby mode. 



Many people would like to carry a cell phone to call or be called only in 
emergencies. Right now this is only convenient for outgoing calls. For incoming 
calls this is tedious at best since it still requires virtually daily charges of the 
battery. Our combination would make this more feasible since the phone could 
be carried for a month or more without recharging. It also has advantages over 
carrying a pager and a switched off cell phone. Aside from the advantage of 
needing to carry only one small device, calls from stations that do not allow 
incoming calls, e.g., payphones, can be taken. 

One could imagine a variety of subscription prices for incoming calls based 
on the type of paging that is made available. Basic pagers typically operate in a 
large region (relative to cell phone cells), but basic service will not cover a large 
country like the US. Someone who regularly travels nationally might opt for a 
more expensive national (or international) paging service. In between these two 
extremes, one could have a phone-pager that operates regionally but updates 
the paging region it is in the first time it is turned on in that region. (Once it 
changes regions, it cannot receive incoming calls until it updates the region.) 

3.2 Private Location Tracking 

The next application we discuss is a location tracking service for which the 
user can control access to his location information. An active badging system 
can provide location information for individuals by sending badge identifiers to 
room sensors. Such a system, for example, has been implemented by Olivetti 
at the Cambridge University Computing Laboratory. While this information is 
useful for tracking people down, it may be a little too useful, making people 
hesitant to use it willingly. If control over access to an individual’s location 
information can be placed in the hands of that individual, the system becomes 
much less threatening. The goal is then to provide a trusted home machine that 
can track the location of its user without centralized tracking information arising 
anywhere else and with limited computation power necessary for the wearable 
tracking device. 

Here is a basic description of such a system. In terms of computing power of 
the wearable device (badge), it requires only that the user’s wearable device share 
a pseudo-random number generator (PRNG) with the user’s home machine. The 
PRNG is used to produce a sequence of tags that will serve roughly as one-time 
passwords. The badge sends a new tag every time it detects a different sensor. 
Once it receives an acknowledgement from the sensor it advances to the next 
tag. The badge must assume that the tag will be sent to the home machine 
at that point. The sensor opens an anonymous connection to the database and 
sends the current tag encrypted for the database and sends a (symmetric) key for 
encrypting the reply. The database looks up the RTA data structure associated 
with that tag (which the home machine has deposited there) and sends it back 
to the sensor. The sensor then uses this to construct an RTA connection to the 
home machine and sends the home machine his name (i.e. , location information) 
and the tag. The principals specified in our protocol are: the wearable badge B, 
the room sensor S, the central database D, and the user’s home machine H . 



1. B detects new S 

2 . B ^ S : Tag 

3. S -> B : Ack 

4. S =? s D : {Tag, K ds } Kd 

5. D =^s S : {(=^h H)}K ds ((=^H H) stored at D under Tag) 

6. S =?h H : S, Tag 

A few assumptions are necessary. We assume that the database is query only. 
This prevents an attacker from reading random RTA data structures from the 
database and confusing the home machine about the whereabouts of the badge. 
Even if attackers could read random RTAs, the attack would not reveal any 
information (but might confuse the home machine with bogus tags). Specifically, 
this attack would not allow an attacker to frame a badge wearer by sending 
a sequence of bogus locations to the home machine since there is no way to 
identify successive tags or matching RTA structures. Despite this, requiring that 
the database be query only will mean that the only way to mount such an 
attack would be to guess tags or to grab them from a badge as it sends them 
out, presumably requiring hardware and a more concerted attack. The home 
machine is assumed to have deposited (over an anonymous connection) an RTA 
structure for each tag. This should not be done in a batch unless the user wants to 
trust the database to know that all of the deposited tags and RTA structures are 
from the same home machine. However, many RTA structures can be deposited 
in advance. In fact, depositing several RTAs in advance makes this protocol 
resistant to attack via spurious Acks. Since each Ack makes the badge move to 
the next tag, spurious Acks might cause the badge and home station to drift 
out of synch. More specifically a query to the central database may not find a 
matching RTA. However, submitting enough RTAs in advance solves the spurious 
Ack problem, provided that the home machine checks ahead whenever it receives 
a tag that does not match the next one expected. The protocol is also resilient to 
lost Acks, even without depositing more than one RTA in advance. If the badge 
does not receive a sent Ack but the matching RTA is used, then only the next 
location update is lost. 

There are some vulnerabilities associated with this protocol. Corrupt sensors 
could fail to acknowledge receipt of the tag. They could then cooperate to track 
the user who would be sending the same tags as it moved about. This attack is 
limited in that the tags will change every time the device encounters a properly 
functioning and uncompromised sensor. The device could also keep track of the 
number of times (or number of successive times) it fails to receive an Ack. If a 
threshold number is exceeded it could either cease to operate or flash or beep to 
indicate an error. This is useful for more than prevention of attacks since failure 
to properly receive Ack s could indicate a malfunction in the wearable device or 
in the locating system. Note that corrupt sensors cannot otherwise cooperate 
with each other or with a corrupt centralized database since there is nothing 
to correlate successive connections to the database. (If a badge moves from the 
range of one corrupt sensor to another, they could of course observe the successive 
connections made. However, even then it might take a good deal of analysis to 



determine which badge is likely to have followed which path, especially if a user 
passes through rooms with several other individuals.) 

An alternative that would prevent the above attack is for a badge to send out 
a new tag at regular intervals, whether it encounters a new sensor or not. This 
probably entails more overhead since individuals are likely to spend extended 
intervals at given locations, e.g., in their offices. Notice that the database cannot 
infer that someone is sedentary (much less who) because there is no way to link 
successive queries as coming from or not coming from the same badge. And, the 
connection to it from the sensors is always anonymous, so it cannot tell whence 
queries come. 

Another alternative protocol avoids the use of anonymous connections en- 
tirely. Here there is no centralized database. Instead sensors simply broadcast 
tags (and sensor IDs) to all home machines. Home machines then pick up those 
tags that are meant for them to track their users. There are a variety of tradeoffs 
between this protocol and those that make use of anonymous connections, e.g., 
cost of anonymous connection set-up vs. cost of broadcast. Which is the better 
approach is likely to be highly contextual. 

4 Background 

Chaum [1] defines a layered object that routes data through intermediate nodes, 
called mixes. These intermediate nodes may reorder, delay, and pad traffic to 
complicate traffic analysis. Chaum’s mixes and related work are the basis for 
almost all subsequent work on anonymous communication. Other approaches to 
anonymity in mobile phone systems occur in [2] and [3]. Another approach to 
private location tracking occurs in [7]. The approach to anonymous connections 
that we have implemented is called onion routing. Onion routing shares many 
anonymity mechanisms with Babel [6] but Babel uses them specifically for e- 
mail, while onion routing uses them to build (possibly long lived) application 
independent connections. We now give a basic description of onion routing; more 
details can be found in [4, 10, 11, 5]. 

4.1 Onion Routing 

Traffic analysis can be used to infer who is talking to whom over a public net- 
work. For example, in a packet switched network like the Internet, packets have a 
header used for routing, and a payload that carries the data. The header, which 
must be visible to the network (and to observers of the network), reveals the 
source and destination of the packet. Even if the header were obscured in some 
way, the packet could still be tracked as it moves through the network. Encrypt- 
ing the payload is similarly ineffective, because the goal of traffic analysis is to 
identify who is talking to whom and not (to identify directly) the content of that 
conversation. 

Onion routing protects against traffic analysis attacks from both the network 
and observers. Onion routing works in the following way: The initiating appli- 
cation, instead of making a connection directly to a responding server, makes 



a connection to an application specific onion routing proxy. That onion rout- 
ing proxy builds an anonymous connection through several other onion routers 
to the destination. Each onion router can only identify adjacent onion routers 
along the route. When the connection is broken, even this limited information 
about the connection is cleared at each onion router. Data passed along the 
anonymous connection appears different at and to each onion router, so data 
cannot be tracked en route and compromised onion routers cannot cooperate. 
An onion routing network can exist in several configurations that permit efficient 
use by both large institutions and individuals. The onion routing proxy defines 
a route through the onion routing network by constructing a layered data struc- 
ture called an onion and sending that onion through the onion routing network. 
Each layer of the onion is public key encrypted for the intended onion router and 
defines the next hop in a route. An onion router that receives an onion peels off 
its layer, reads from that layer the name of the next hop and the cryptographic 
information associated with its hop in the anonymous connection, pads the em- 
bedded onion to some constant size, and sends the padded onion to the next 
onion router. 

Before sending data over an anonymous connection, the initiator’s onion 
routing proxy adds a layer of encryption for each onion router in the route. 
As data moves through the anonymous connection, each onion router removes 
one layer of encryption, so it finally arrives as plaintext. The last onion router 
forwards data to another type of proxy, called the responder’s proxy, whose job is 
to pass data between the onion network and the responding server. This layering 
occurs in the reverse order for data moving back to the initiator. So data that 
has passed backward through the anonymous connection must be repeatedly 
decrypted to obtain the plaintext. 

5 Conclusion 

This paper presents a means for talking about anonymous connections and proto- 
cols that make use of them. We demonstrate the usefulness of describing anony- 
mous connections at this level of abstraction by using our notation to describe 
two protocols for location protected communication over a public infrastructure. 
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